home *** CD-ROM | disk | FTP | other *** search
/ Chip 2000 October / CHIP Turkiye Ekim 2000.iso / prog / naps / 16 / napster.txt < prev    next >
Encoding:
Text File  |  2000-07-19  |  39.0 KB  |  1,370 lines
  1. napster messages
  2. ================
  3.  
  4. by drscholl@users.sourceforge.net
  5. July 19, 2000
  6.  
  7. 0.  Foreward
  8.  
  9. This is meant to be an open specification.  If you find errors or know of
  10. additional functionality not described hereafter, please send me email.  It
  11. benefits the entire community to have a complete and accurate protocol
  12. specification.  Not only does it allow for clients to be developed for any
  13. platform, but also decreases the strain on the server having to parse out
  14. bad client messages.
  15.  
  16. Disclaimer: the following information was gathered by analyzing the protocol
  17. between the linux nap client and may not resemble the official Windows client
  18. protocol.
  19.  
  20. 1.  Client-Server protocol
  21.  
  22. each message to/from the server is in the form of
  23. <length><type><data>
  24. where <length> and <type> are 2 bytes each.  <length> specifies the length in
  25. bytes of the <data> portion of the message.  Be aware that <length> and <type>
  26. appear to be in little-endian format (least significant byte goes first).  For
  27. example, in the C language you would encode the number 1 as
  28.     const unsigned char num[2] = { 0x01, 0x00 };
  29. and 256 would be encoded as
  30.     const unsigned char num[2] = { 0x00, 0x01 };
  31. [The above is for illustrative purposes only, there are much quicker ways to
  32. actually encode a number. -ed]
  33.  
  34. Note that in many cases, strings are passed as double-quoted entries.  For
  35. example, filenames and client id strings are always sent as
  36.     "random band - generic cowboy song.mp3"
  37. or
  38.     "nap v0.8"
  39. Where required, double quotes are used in the description of the messages
  40. below.
  41.  
  42. Some additional information about use of quotes inside of quotes:
  43. > The answer is, no, it doesn't do escaping of quotes.  If you try searching
  44. > for the phrase 'a "quoted" string' on the windows client, you get no songs
  45. > found, and "invalid search request" printed in yellow in your console
  46. > window.  (don't know what code that is, sorry.)
  47. >
  48. > and no wonder-- a little birdie told me that the client sends this:
  49. >
  50. > FILENAME CONTAINS "a "quoted" string" MAX_RESULTS 100
  51.  
  52. [contributed by Ben Byer <bbyer@rice.edu>.  -ed]
  53.  
  54. Note that unlike the IRC protocol, each line does NOT end in \r\n.  The
  55. <length> field specifies exactly how much data you should read.
  56.  
  57. 2.  Message Types
  58.  
  59. The following section describes the format of the <data> section for each
  60. specific message type.  Each field is denoted with <>.  The fields in a
  61. message are separated by a single space character (ASCII 32).  Where
  62. appropriate, examples of the <data> section for each message are given.
  63.  
  64. <type> can be one of the following (converted to big-endian):
  65.  
  66. 0    error message [SERVER]
  67.  
  68.     Format: <message>
  69.  
  70. 2    login [CLIENT]
  71.  
  72.     Format: <nick> <password> <port> "<client-info>" <link-type> [ <num> ]
  73.  
  74.     <port> is the port the client is listening on for data transfer.  if
  75.         this value is 0, it means that the client is behind a firewall
  76.         and can only push files outward.  it is expected that requests
  77.         for downloads be made using the 500 message (see below)
  78.     <client-info> is a string containing the client version info
  79.     <link-type> is an integer indicating the client's bandwidth
  80.         0  unknown
  81.         1  14.4 kbps
  82.         2  28.8 kpbs
  83.         3  33.6 kbps
  84.         4  56.7 kbps
  85.         5  64K ISDN
  86.         6  128K ISDN
  87.         7  Cable
  88.         8  DSL
  89.         9  T1
  90.         10 T3 or greater
  91.     <num> build number for the windows client [optional]
  92.         
  93.     Example:
  94.  
  95.     foo badpass 6699 "nap v0.8" 3
  96.  
  97. 3    login ack [SERVER]
  98.  
  99.     Format: <email>
  100.  
  101.     the server sends this message to the client after a succesful
  102.     login (2).  If the nick is registered, the <email> address given at
  103.     registration time is returned.  If the nick is not registered, a
  104.     dummy value is returned.
  105.  
  106. 4       version check [CLIENT]
  107.  
  108.         Format: <version>
  109.  
  110.     Server sends [5] if an update is needed. All other responses are
  111.     ignored.
  112.  
  113.     <version> = string, version 2.0b5a sends "2.0"
  114.  
  115. 5       "auto-upgrade" [SERVER]
  116.  
  117.         Format: <version> <hostname:filename>
  118.  
  119.         Napster is out of date, get a new version.
  120.         Or also known as gaping security hole.
  121.  
  122.         <version>  = string, the new version number.
  123.         <hostname> = string, hostname of upgrade (http) server
  124.         <filename> = string, filename
  125.  
  126.         Connections are always made to port 80.
  127.  
  128.         The HTTP Request:
  129.                 GET <filename> HTTP/1.0
  130.                 Connection: Keep-Alive
  131.                 Host: <hostname>
  132.  
  133.         Expected HTTP Response.
  134.                 Content-Length: <size>
  135.                 Content-Type: <doesn't matter>
  136.                 <data>
  137.  
  138.         Upgrade file is save as "upgrade.exe".
  139.         And executed as: upgrade.exe UPGRADE "<current.exe>"
  140.  
  141.         As far as I can tell no confirmation is requested by Napster when it
  142.         receives this message.  And immediately start to "auto-upgrade". To keep
  143.         users informed that Napster is doing something potentially very harmful
  144.         to their computer it displays a message saying it's "auto-upgrading".
  145.  
  146.         I think this pretty bad, since all someone has to do is hack a napster
  147.         server et voila a zillion clients at your disposal.
  148.  
  149.         As far as I known this only affects the Win32 2.0b5a Napster client.
  150.         Other clients/versions I don't know.
  151.  
  152.     [This section was contributed by Thomas van der Heijden <thom@bart.nl>
  153.     -ed]
  154.  
  155. 6    new user login [CLIENT]
  156.  
  157.     Format: <nick> <pass> <port> "<client-info>" <speed> <email-address>
  158.  
  159.     This message is used when logging in for the first time to register
  160.     a new nickname.  The client normally checks for an unused nick using
  161.     the "check nickname" (7) message and upon receipt of a "nickname not
  162.     registered" (8) from the server will proceceed to log in with this
  163.     command.
  164.  
  165.     note: this message is similar to the 0x02 message, with the addition    
  166.     of <email-address> on the end
  167.  
  168.     Example:
  169.  
  170.     foo foo 6699 "nap v0.8" 3 email@here.com
  171.  
  172. 7    nick check [CLIENT]
  173.  
  174.     Format: <nick>
  175.  
  176.     Queries the server to see if <nick> is already registered.  This
  177.     message is typically used prior to logging in for the first time to
  178.     check for a valid nickname.
  179.  
  180.     Response to this message is one of 8, 9 or 10
  181.  
  182. 8    nickname not registered [SERVER]
  183.  
  184.     Format: (empty)
  185.  
  186.     The server sends this message in response to the "nick check" (7)
  187.     message to indicate that the specified nickname is not already
  188.     registered and is ok to use.
  189.  
  190. 9    nickname already registered [SERVER]
  191.  
  192.     Format: (empty)
  193.  
  194.     The server sends this message when the nickname the client has
  195.     requested has already been registered by another user
  196.  
  197. 10    invalid nickname [SERVER]
  198.  
  199.     Format: (empty)
  200.  
  201.     This server sends this message in response to the "check nickname"
  202.     (7) messages when the specified nickname is invalid, usually due to
  203.     bad characters such as spaces or other non-printable characters.
  204.  
  205. 11    ??? [CLIENT]
  206.  
  207.     Format: <nick> <pass>
  208.  
  209.     [returns "parameters are unparsable" -ed]
  210.  
  211. 12    ??? [SERVER]
  212.  
  213.     Format: (empty)
  214.  
  215.     this message is returned in response to message 11 from the client
  216.  
  217. 14    login options [CLIENT]
  218.  
  219.     NAME:%s ADDRESS:%s CITY:%s STATE:%s PHONE:%s AGE:%s INCOME:%s EDUCATION:%s
  220.  
  221.     Example:
  222.  
  223.     NAME: kev  ADDRESS:  CITY: ephrata  STATE: pa  PHONE:  AGE: 60 or older INCOME: $100,000 or more        EDUCATION: Graduate Degree
  224.  
  225. 100    client notification of shared file [CLIENT]
  226.  
  227.     Format: "<filename>" <md5> <size> <bitrate> <frequency> <time>
  228.  
  229.     <md5> see section "MD5"
  230.     <size> is bytes
  231.     <bitrate> is kbps
  232.     <frequency> is hz
  233.     <time> is seconds
  234.     
  235.     Example:
  236.  
  237.     "generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7 443332 128 44100 60
  238.  
  239. 102    remove file [CLIENT]
  240.  
  241.     Format: <filename>
  242.  
  243.     client requests to remove file from shared library
  244.  
  245. 200    client search request [CLIENT]
  246.  
  247.     [FILENAME CONTAINS "artist name"] MAX_RESULTS <max> [FILENAME CONTAINS
  248. "song"] [LINESPEED <compare> <link-type>] [BITRATE <compare> "<br>"] [FREQ
  249. <compare> "<freq>"]
  250.  
  251.         The artist name and the song name are, obviously, treated
  252.                 the same by the server; confirm this for yourself
  253.                 on the windows client.
  254.  
  255.         max is a number; if it is greater than 100, the server will
  256.                 only return 100 results.
  257.  
  258.         <compare> is one of the following:
  259.                 "AT LEAST" "AT BEST" "EQUAL TO"
  260.  
  261.         <link-type> see 0x02 (client login) for a description
  262.  
  263.         <br> is a number, in kbps
  264.  
  265.         <freq> is a sample frequency, in Hz
  266.  
  267.         The windows client filters by ping time inside the client.
  268.                 It pretty much has to, and it's easy to see the
  269.                 result by setting ping time to at best 100 ms or
  270.                 so, and max search terms to 50.  You'll get back
  271.                 like 3 results, but the client will still tell you
  272.                 that it found "50 results".
  273.  
  274.         Examples:
  275.                 FILENAME CONTAINS "Sneaker Pimps" MAX_RESULTS 75 FILENAME
  276.                          CONTAINS "tesko suicide" BITRATE "AT LEAST" "128"
  277.  
  278.                 MAX_RESULTS 100 FILENAME CONTAINS "Ventolin" LINESPEED
  279.                         "EQUAL TO" 10
  280.  
  281.     [Thanks to Ben Byer <bbyer@rice.edu> for this contribution.  -ed]
  282.  
  283. 201    search response [SERVER]
  284.  
  285.     "<filename>" <md5> <size> <bitrate> <frequency> <length> <nick> <ip> <link-type>
  286.  
  287.     <md5> see secton "MD5"
  288.     <size> is file size in bytes
  289.     <bitrate> is mp3 bit rate in kbps
  290.     <frequency> is sample rate in hz
  291.     <length> is the play length of the mp3 in seconds
  292.     <nick> the person sharing the file
  293.     <ip> is an unsigned long integer representing the ip address of the
  294.         user with this file
  295.     <link-type> see message client login (2) message for a description
  296.  
  297.     Example:
  298.  
  299.     "random band - random song.mp3" 7d733c1e7419674744768db71bff8bcd 2558199 128 44100 159 lefty 3437166285 4
  300.  
  301. 202    end of search response from server [SERVER]
  302.  
  303.     Format: (empty)
  304.  
  305. 203    download request [CLIENT]
  306.  
  307.     Format: <nick> "<filename>"
  308.  
  309.     client requests to download <filename> from <nick>.  client expects
  310.     to make an outgoing connection to <nick> on their specified data
  311.     port.
  312.  
  313.     Example:
  314.  
  315.     mred "C:\Program Files\Napster\generic cowboy song.mp3"
  316.  
  317.     SEE ALSO: 500 alternate download request
  318.  
  319. 204    download ack [SERVER]
  320.  
  321.     <nick> <ip> <port> "<filename>" <md5> <linespeed>
  322.  
  323.     server sends this message in response to a 203 request.
  324.  
  325.     <nick> is the user who has the file
  326.     <ip> is an unsigned long integer representing the ip address
  327.     <port> is the port <nick> is listening on
  328.     <filename> is the file to retrieve
  329.     <md5> is the md5 sum
  330.     <linespeed> is the user's connection speed (see login(2))
  331.  
  332.     Example:
  333.  
  334.     lefty 4877911892 6699 "generic band - generic song.mp3" 10fe9e623b1962da85eea61df7ac1f69 3
  335.  
  336. 205    private message to/from another user [CLIENT, SERVER]
  337.  
  338.     <nick> <message>
  339.  
  340.     note the same type is used for a client sending a msg or recieving one
  341.  
  342.     [Commentary: this message causes problems if you consider linking
  343.     servers together.  With the current one server situation, the server
  344.     just rewrites the message it receives with the name of the client that
  345.     sent it and passes it to the recipient client.  However, in the case
  346.     where the recipient and sender are not on the same server, there is
  347.     loss of information without encapsulating it.  It would have been
  348.     better to put both the sender and recipient because if the servers
  349.     are ever linked they will have to make a new message type for this
  350.     situation.  -ed]
  351.  
  352. 206    get error [SERVER]
  353.  
  354.     <nick> <filename>
  355.  
  356.     the server sends this message when the file that the user has
  357.     requested to download is unavailable (such as the user is not logged
  358.     in).
  359.  
  360. 207    add hotlist entry [CLIENT]
  361.  
  362.     <user>
  363.  
  364.     This message is used to add additional entries to the client's
  365.     hotlist.  The server will send 209 and 210 messages when a user
  366.     on the hotlist has logged in or out, respectively.
  367.  
  368. 208    hotlist [CLIENT]
  369.  
  370.     <user>
  371.  
  372.     This message is used to send the initial list of hotlist entries
  373.     during the initial login process.  It is normally send prior to
  374.     to the add file (100) commands.  To add more entries to the hotlist
  375.     after the initial list is sent, clients should use the 207 message
  376.     instead.
  377.  
  378. 209    user signon [SERVER]
  379.  
  380.     <user> <speed>
  381.  
  382.     server is notifying client that a user in their hotlist, <user>,
  383.     has signed on the server with link <speed>
  384.  
  385. 210    user signoff [SERVER]
  386.  
  387.     <user>
  388.  
  389.     server is notifying client that a user on their hotlist, <user>, has
  390.     signed off the server.
  391.  
  392.     this message is also sent by the server when the client attempts to
  393.     browse a nonexistent client.  [why don't they just use 404 for
  394.     this? -ed]
  395.  
  396. 211    browse a user's files [CLIENT]
  397.  
  398.     <nick>
  399.  
  400.     the client sends this message when it wants to get a list of the files
  401.     shared by a specific client
  402.  
  403. 212    browse response [SERVER]
  404.  
  405.     <nick> "<filename>" <md5> <size> <bitrate> <frequency> <time>
  406.  
  407.     <nick> is the user contributing the file
  408.     <filename> is the mp3 file contributed
  409.     <md5> is the has of the mp3 file
  410.     <size> is the file size in bytes
  411.     <bitrate> is the mp3 bitrate in kbps
  412.     <frequence> is the sampling frequency in Hz
  413.     <time> is the play time in seconds
  414.  
  415.     Example:
  416.  
  417.     foouser "generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7 443332 128 44100 60
  418.  
  419. 213    end of browse list [SERVER]
  420.  
  421.     <nick>
  422.  
  423.     indicates no more entries in the browse list for <user>
  424.  
  425. 214    server stats [CLIENT, SERVER]
  426.  
  427.     client: no data
  428.     server: <users> <# files> <size>
  429.  
  430.     <size> is approximate total library size in gigabytes
  431.     this message is sent by the server occasionaly without request
  432.  
  433.     Example:
  434.  
  435.     553 64692 254
  436.  
  437. 215    request resume [CLIENT]
  438.  
  439.     <checksum> <filesize>
  440.  
  441.     client is requesting a list of all users which have the file with
  442.     the characteristics.  the server responds with a list of 216 messages
  443.     for each match, followed by a 217 message to terminate the list
  444.  
  445. 216    resume search response [SERVER]
  446.  
  447.     <user> <ip> <port> <filename> <checksum> <size> <speed>
  448.  
  449.     this message contains the matches for the resume request (215).  the
  450.     list is terminated by a 217 message.
  451.  
  452. 217    end of resume search list [SERVER]
  453.  
  454.     no data.
  455.  
  456.     this messag terminates a list of 216 messages initiated by a 215
  457.     client request
  458.  
  459. 218    downloading file [CLIENT]
  460.  
  461.     no body.
  462.  
  463.     client sends this message to the server to indicate they are in the
  464.     process of downloading a file.  this adds 1 to the download count
  465.     which the server maintains.
  466.  
  467. 219    download complete [CLIENT]
  468.  
  469.     no body.
  470.  
  471.     client sends this message to the server to indicate they have
  472.     completed the file for which a prior 218 message was sent.  this
  473.     subtracts one from the download count the server maintains
  474.  
  475. 220    uploading file [CLIENT]
  476.  
  477.     no body.
  478.  
  479.     client sends this message to indicate they are uploading a file.
  480.     this adds one to the upload count maintained by the server.
  481.  
  482. 221    upload complete [CLIENT]
  483.  
  484.     no body.
  485.  
  486.     client sends this message when they are finished uploading a file.
  487.     this subtracts one from the upload count maintained by the server.
  488.  
  489. 300    optional ports [CLIENT]
  490.  
  491.     <port>
  492.  
  493.     This command allows the client to specify optional ports to try for
  494.     data connections if the one currently in use is unreachable by other
  495.     parties.
  496.  
  497. 301    hotlist ack [SERVER]
  498.  
  499.     <user>
  500.  
  501.     server is notifying client that <user> has successfully be added to
  502.     their hotlist
  503.  
  504. 302    hotlist error [SERVER]
  505.  
  506.     <user>
  507.  
  508.     server is notifying client that it was unable to add <user> to their
  509.     hotlist.  [can you only add registered nicks to your hotlist? -ed]
  510.  
  511. 303    remove user from hotlist [CLIENT]
  512.  
  513.     <user>
  514.  
  515.     client is notifying the server that it no longer wishes to request
  516.     notifications about <user> when they sign on or off the server.  no
  517.     response is sent in return.
  518.  
  519. 310    ??? [CLIENT, SERVER]
  520.  
  521.     client: no data
  522.     server: 0
  523.  
  524.     unknown command.  server returns 0 regardless of any parameters
  525.  
  526. 316    ??? [CLIENT, SERVER]
  527.  
  528.     client: no data
  529.     server: 0
  530.  
  531.     unknown command.  server returns 0 regardless of any parameters
  532.  
  533. 320    user ignore list [CLIENT, SERVER]
  534.  
  535.     client: no data
  536.     server: <count>
  537.  
  538.     client request to display the list of ignored users.
  539.     server returns the number of users being ignored
  540.  
  541. 321    user ignore list entry [SERVER]
  542.  
  543.     <user>
  544.  
  545.     server sends each ignored nick in response to a 320 request.  the
  546.     list is terminated by a 320 message with the number of ignored users.
  547.  
  548. 322    add user to ignore list [CLIENT, SERVER]
  549.  
  550.     <user>
  551.  
  552.     server acks the request by returning the nick
  553.  
  554. 323    remove user from ignore list [CLIENT]
  555.  
  556.     <user>
  557.  
  558.     server acks the request by returning the nick to be removed from
  559.     the ignore list.
  560.  
  561. 324    user is not ignored [SERVER]
  562.  
  563.     <user>
  564.  
  565.     server indicates that <user> is not currently ignored in response to
  566.     a 323 request.
  567.  
  568. 325    user is already ignored [SERVER]
  569.  
  570.     <user>
  571.  
  572.     server indicates the specified user is already on the user's ignore
  573.     list
  574.  
  575. 326    clear ignore list [CLIENT, SERVER]
  576.  
  577.     client: no data.
  578.     server: <count>
  579.  
  580.     client requests the server clear its ignore list.  server returns the
  581.     number of entries removed from the ignore list.
  582.  
  583. 330    blocked ip list [CLIENT]
  584.  
  585. 332    block ip [CLIENT]
  586.  
  587. 333    unblock ip [CLIENT]
  588.  
  589. 400    join channel [CLIENT]
  590.  
  591.     <channel-name>
  592.  
  593.     the client sends this command to join a channel
  594.  
  595. 401    part channel [CLIENT, SERVER]
  596.  
  597.     <channel-name>
  598.  
  599.     The client sends this command to part a channel.  Server sends this
  600.     message to indicate that the client has parted the channel.  Note
  601.     that this is sometimes sent even when the client has not requested,
  602.     so a client _must_ be prepared to accept it at any time.
  603.  
  604. 402    send public message [CLIENT]
  605.  
  606.     <channel> <message>
  607.  
  608. 403    public message [SERVER]
  609.  
  610.     <channel> <nick> <text>
  611.  
  612.     this message is sent by the server when a client sends a public message
  613.     to a channel.
  614.  
  615.     Example:
  616.  
  617.     80's espinozaf hello...hola
  618.  
  619. 404    error message [SERVER]
  620.  
  621.     <text>
  622.  
  623.     This message is used to send general error messages to a client that
  624.     is logged in.  Note: Message 0 is only sent during the login process.
  625.  
  626.     Examples:
  627.  
  628.     User nosuchuser is not currently online.
  629.     Channel #nosuchchannel does not exist!
  630.     permission denied
  631.     ping failed, blah is not online
  632.  
  633. 405    join acknowledge [SERVER]
  634.  
  635.     <channel>
  636.  
  637.     the server sends this message to the client to acknowlege that it
  638.     has joined the requested channel (400)
  639.     
  640. 406    join message [SERVER]
  641.  
  642.     <channel> <user> <sharing> <link-type>
  643.  
  644.     <user> has joined <channel>
  645.  
  646.     Example:
  647.  
  648.     80's WilmaFlinstone 12 2
  649.  
  650. 407    user parted channel [SERVER]
  651.  
  652.     <channel> <nick> <sharing> <linespeed>
  653.  
  654.     Example:
  655.  
  656.     80's DLongley 23 7
  657.  
  658. 408    channel user list entry [SERVER]
  659.  
  660.     this message is identical to the join (406) message.  the server will
  661.     send the list of users in the channel prior to the client join command
  662.     in this message.  joins that occur after the client has joined will
  663.     be noted by a 406 message.
  664.  
  665. 409    end of channel user list [SERVER]
  666.  
  667.     <channel>
  668.  
  669.     this message is sent by the server to indicate it has sent all informati    about the users in a channel
  670.  
  671. 410    channel topic [CLIENT, SERVER]
  672.  
  673.     <channel> <topic>
  674.  
  675.     sent when joining a channel or a new topic is set.  a client requesting
  676.     topic change also uses this message.
  677.  
  678.     [why didn't they put a field to indicate WHO changed the topic?  as
  679.     it is now you can only tell that it was changed.  -ed]
  680.  
  681. 420    channel ban list [CLIENT]
  682.  
  683.     <channel>
  684.  
  685. 421    channel ban list entry [SERVER]
  686.  
  687. 422    channel ban [CLIENT]
  688.  
  689.     <channel> <user|ip> [ "<reason>" ]
  690.  
  691. 423    channel unban [CLIENT]
  692.  
  693.     <channel> <user|ip> [ "<reason>" ]
  694.  
  695. 424    channel ban clear [CLIENT]
  696.  
  697.     Format: <channel>
  698.  
  699. 425    alternate topic (?) [SERVER]
  700.  
  701.     Format: <message>
  702.  
  703.     [The server sends this command when a user joins one of the
  704.     predefined channels.  It seems to send a default message if the
  705.     topic for the channel is the default, otherwise it sends the current
  706.     channel topic.  -ed]
  707.  
  708. 500    alternate download request [CLIENT]
  709.  
  710.     <nick> "<filename>"
  711.  
  712.     requests that <nick> make an outgoing connection to the requesters
  713.     client and send <filename>.  this message is for use when the
  714.     person sharing the file can only make an outgoing tcp connection
  715.     because of firewalls blocking incoming messages.  this message should
  716.     be used to request files from users who have specified their data
  717.     port as 0 in their login message
  718.  
  719. 501    alternate download ack [SERVER]
  720.  
  721.     <nick> <ip> <port> "<filename>" <md5> <speed>
  722.  
  723.     this message is sent to the uploader when their data port is set to
  724.     0 to indicate they are behind a firewall and need to push all data
  725.     outware.  the uploader is responsible for connecting to the
  726.     downloader to transfer the file.
  727.  
  728. 600    request user's link speed [CLIENT]
  729.  
  730.     <nick>
  731.  
  732. 601    link speed response [SERVER]
  733.  
  734.     <nick> <linespeed>
  735.  
  736. 602    ??? [CLIENT]
  737.  
  738.     <?>
  739.  
  740.     server returns a 404 with "*gulp* Drink milk, it does a body good!"
  741.  
  742. 603    whois request [CLIENT]
  743.  
  744.     <nick>
  745.  
  746. 604    whois response [SERVER]
  747.  
  748.     <nick> "<user-level>" <time> "<channels>" "<status>" <shared>
  749.     <downloads> <uploads> <link-type> "<client-info>" [ <total downloads>
  750.     <total_uploads> <ip> <connecting port> <data port> <email> ]
  751.  
  752.     <user-level> is one of "User", "Moderator", "Admin" or "Elite"
  753.     <time> is seconds this user has been connected
  754.     <channels> is the list of channels the client is a member of, each
  755.         separated by a space (ASCII 32)
  756.     <status> is one of "Active", "Inactive" (offline) or "Remote" (on a
  757.         different server)
  758.     <shared> is number of files user has available for download
  759.     <downloads> is the current number of downloads in progress
  760.     <uploads> is the current number of uploads in progress
  761.     <link-type> see 0x02 (client login) above
  762.     <client-info> see 0x02 (client login) above
  763.  
  764.     The following fields are displayed for user level moderator and
  765.     above:
  766.  
  767.     <total uploads>
  768.     <total downloads>
  769.     <ip>            note: can be "unavailable"
  770.     <connecting port>
  771.     <data port>
  772.     <email>            note: can be unavailable
  773.  
  774.     Example:
  775.  
  776.     lefty "User" 1203 "80's " "Active" 0 0 0 3 "nap v0.8"
  777.  
  778. 605    whowas response [SERVER]
  779.  
  780.     <user> <level> <last-seen>
  781.  
  782.     if the user listed in a 603 request is not currently online, the
  783.     server sends this message.
  784.  
  785.     <user> is the user for which information was requested
  786.     <level> is the user's last known userlevel (user/mod/admin)
  787.     <last-seen> is the last time at which this user was seen, measured
  788.         as seconds since 12:00am on January 1, 1970 (UNIX time_t).
  789.  
  790. 606    change user level [CLIENT]
  791.  
  792.     <nick> <level>
  793.  
  794.     changes the privileges for <nick> to <level>.  client must be admin
  795.     level to execute this request
  796.  
  797.     [I have not verified this message since I don't have admin status
  798.     on any of the servers.  -ed]
  799.  
  800. 607    upload request [SERVER]
  801.  
  802.     <nick> "<filename>"
  803.  
  804.     this message is used to notify the client that user <nick> has
  805.     requested upload of <filename>
  806.  
  807.     Example:
  808.  
  809.     lefty "generic band - generic song.mp3"
  810.  
  811. 608    accept upload request [CLIENT]
  812.  
  813.     <nick> "<filename>"
  814.  
  815.     client is notifying server that upload of <filename> to <nick> is
  816.     accepted, and that the requesting client may begin download
  817.  
  818.     Example:
  819.  
  820.     lefty "generic band - generic song.mp3"
  821.  
  822. 609     get error [SERVER]      (same as [206])
  823.  
  824.         <nick> <filename>
  825.  
  826.         the server sends this message when the file that the user has
  827.         requested to download is unavailable (such as the user is not logged
  828.         in).
  829.  
  830. 610    kill (disconnect) a user [CLIENT]
  831.  
  832.     <nick>
  833.  
  834.     client request to disconnect a user.
  835.  
  836. 611    nuke a user [CLIENT]
  837.  
  838.     <nick>
  839.  
  840.     client request to delete account for <nick>
  841.  
  842. 612    ban user [CLIENT]
  843.  
  844.     <nick | ip> [ "<reason>" ]
  845.  
  846.     client request to place a ban on either a specific nickname or
  847.     an ip address
  848.  
  849. 613    set data port for user [CLIENT, SERVER]
  850.  
  851.     client: <user> <port>
  852.     server: <port>
  853.  
  854.     This command is used by administrators to request that another
  855.     client set the port used for data transfers to <port>.  The server
  856.     sends a message with the requested port number to the target
  857.     client.  NOTE: the target client can change its port number to
  858.     whatever it wishes using the 703 command.
  859.  
  860. 614    unban user [CLIENT]
  861.  
  862.     Format: <nick | ip> [ "<reason>" ]
  863.  
  864. 615    show bans for server [CLIENT]
  865.  
  866.     Format: (empty)
  867.  
  868.     client requests the list of banned ips for the current server
  869.  
  870. 616    (ip?) ban list entry [SERVER]
  871.  
  872.     Format: <ip> <nick> "<reason>" <time> <n>
  873.  
  874.     <ip> is the string version of the ip banned
  875.     <nick> is the user setting the ban
  876.     <reason> is the reason given
  877.     <time> is the time_t when the ban was set
  878.     <n> is ???.  value is either 0 or 1
  879.  
  880.     This message is sent in response to the 615 client request, one
  881.     for each ban.  The list is terminated with a 0 length 615 message
  882.     from the server.
  883.  
  884.     Example:
  885.     
  886.     207.172.245. valkyrie "DoS exploit" 947304224 0
  887.  
  888. 617    list channels [CLIENT, SERVER]
  889.  
  890.     Format: (empty)
  891.  
  892.     client requests a list of channels on the server.  server responds
  893.     with 618/617
  894.  
  895.     server indicates end of channel list using this message.
  896.  
  897. 618    channel list entry [SERVER]
  898.  
  899.     Format: <channel-name> <number-of-users> <topic>
  900.  
  901.     this is the server response to a 617 client request, one for each
  902.     channel.
  903.  
  904.     Example:
  905.  
  906.     Help 50 OpenNap help channel
  907.  
  908. 619    queue limit [CLIENT]
  909.  
  910.     Format: <nick> "<filename>" <n>
  911.  
  912.     a client may limit the number of downloads from a particular client.
  913.     once the limit for a particular user has been reached, the uploading
  914.     client can send this message to notify the downloader that they
  915.     have hit the limit and can't have any more simultaneous downloads.
  916.     <nick> is the user who hit the limit, <filename> is the file they
  917.     were trying to download when they hit the limit, and <n> is the
  918.     number of simultaneous downloads allowed.
  919.  
  920.     Example:
  921.  
  922.     joebob "C:\MP3\Generic Band - Generic Song.mp3" 3
  923.  
  924. 620    queue limit [SERVER]
  925.  
  926.     <nick> "<filename>" <filesize> <digit>
  927.  
  928.     This message is sent by the server in response to the 619 client
  929.     request, when one user needs to notify another that they have
  930.     reached the maximum allowed simultaneous downloads.  When the server
  931.     recieves the 619 request from the uploading client, it sends the 620
  932.     message to the downloading client.  The only difference in format is
  933.     the addition of the <nick> field in the 620 message which specifies
  934.     the username of the uploading agent which is notifying the
  935.     downloader that the queue is full.
  936.  
  937.     Example:
  938.  
  939.     joebob "C:\MP3\Generic Band - Generic Song.mp3" 1234567 3
  940.  
  941. 621    message of the day [CLIENT, SERVER]
  942.  
  943.     <text>
  944.  
  945.     Server: each 621 message contains a single line of text
  946.  
  947.     Client: client sends a 621 command with no data to request the
  948.     motd be sent.  The server will usually send this automatically after
  949.     a user logs in, so this command allows a user to reread it upon
  950.     request.
  951.  
  952. 622    muzzle a user [CLIENT]
  953.  
  954.     <nick> [ "<reason>" ]
  955.  
  956.     client requests that <nick> not be allowed to send public messages
  957.  
  958. 623    unmuzzle a user [CLIENT]
  959.  
  960.     <nick> [ "<reason>" ]
  961.  
  962.     client requests that the enforced silence on <nick> be lifted
  963.  
  964. 624    un-nuke a user [CLIENT]
  965.  
  966.     <user>
  967.  
  968. 625    change a user's linespeed [CLIENT]
  969.  
  970.     <user> <speed>
  971.  
  972. 626    data port error [CLIENT, SERVER]
  973.  
  974.     <user>
  975.  
  976.     When a downloading client detects that the uploader's data port
  977.     is unreachable, it should send a 626 message to the server with
  978.     the nick of the user for which the connection failed.  The server
  979.     then relays the message to the uploader, substituing the
  980.     downloader's nickname in the message.
  981.  
  982. 627    operator message [CLIENT, SERVER]
  983.  
  984.     client: <text>
  985.     server: <nick> <text>
  986.  
  987.     client request to send a message to all admins/moderators
  988.  
  989. 628    global message [CLIENT, SERVER]
  990.  
  991.     client: <text>
  992.     server: <nick> <text>
  993.  
  994.     client request send a message to all users
  995.  
  996. 629    banned users [SERVER]
  997.  
  998.     Format: <nick>
  999.  
  1000.     when displaying the ban list for the server, this message is used
  1001.     to indicate banned nicknames.
  1002.  
  1003. 630-649    missing
  1004.  
  1005. 650-651    ??? [CLIENT]
  1006.  
  1007.     permission denied.
  1008.  
  1009. 652    cloak user [CLIENT]
  1010.  
  1011.     sets the current user to "invisible"
  1012.  
  1013. 653-699    missing.
  1014.  
  1015. 700    change link speed [CLIENT]
  1016.  
  1017.     <speed>
  1018.  
  1019.     client is notifying server that its correct link speed is <speed>,
  1020.     in the range 0-10 (see the login message for details).
  1021.  
  1022. 701    change user password [CLIENT]
  1023.  
  1024.     <password>
  1025.  
  1026.     client wishes to change their password
  1027.  
  1028. 702    change email address [CLIENT]
  1029.  
  1030.     <email address>
  1031.  
  1032.     client wishes to change their email address
  1033.  
  1034. 703    change data port [CLIENT]
  1035.  
  1036.     <port>
  1037.  
  1038.     client is changing the data port being listened on for file
  1039.     transfers
  1040.  
  1041. 704-747    missing.
  1042.  
  1043. 748    login attempt [SERVER]
  1044.  
  1045.     the server sends this message to a logged in client when another
  1046.     client attempts to log in with the same nickname.
  1047.  
  1048. 749    missing.
  1049.  
  1050. 750    server ping [CLIENT, SERVER]
  1051.  
  1052.         server: none
  1053.         client: <user>
  1054.  
  1055.         Napster 2.0b5a sends the username in a response to a 750 from the
  1056.     server.
  1057.  
  1058.     [server returns an empty 750 command in response. server ping? -ed]
  1059.  
  1060. 751    ping user [CLIENT, SERVER]
  1061.  
  1062.     <user>
  1063.  
  1064.     client is attempting to determine if <user>'s connection is alive
  1065.  
  1066. 752    pong response [CLIENT, SERVER]
  1067.  
  1068.     <user>
  1069.  
  1070.     this message is sent in response to the the 751 (PING) requeset
  1071.  
  1072. 753    change password for another user [CLIENT]
  1073.  
  1074.     <user> <password> "<reason>"
  1075.  
  1076.     allows an administrator to change the password for another user
  1077.  
  1078. 754-769    missing.
  1079.  
  1080. 770    ??? [CLIENT]
  1081.  
  1082.     permission denied.
  1083.  
  1084. 771    ??? [CLIENT]
  1085.  
  1086.     permission denied.
  1087.  
  1088. 772-799    missing.
  1089.  
  1090. 800    reload config [CLIENT]
  1091.  
  1092.     <config variable>
  1093.  
  1094.     resets configuration parameter to its default value
  1095.  
  1096. 801    server version [CLIENT]
  1097.  
  1098.     no data.
  1099.  
  1100.     client request's a server's version
  1101.  
  1102. 802-804    missing.
  1103.  
  1104. 805    ???
  1105.  
  1106.     [returns permission denied. -ed]
  1107.  
  1108. 810    set config [CLIENT]
  1109.  
  1110.     <config string>
  1111.  
  1112.     request a change in server configuration variables
  1113.  
  1114. 811    ???
  1115.  
  1116.     [returns permission denied. -ed]
  1117.  
  1118. 820    clear channel
  1119.  
  1120.     <channel>
  1121.  
  1122.     remove all users from the specified channel
  1123.  
  1124. 821    ??? [CLIENT, SERVER]
  1125.  
  1126.     client: <user> <?> <?>
  1127.     server: <?> <?>
  1128.     
  1129.     [no idea what this is for.  it sends the two arguments after the
  1130.     nick to <user>.  all additional parameters seem to be dropped.  -ed]
  1131.  
  1132. 822    ??? [CLIENT, SERVER]
  1133.  
  1134.     client: <user> <?>
  1135.     server: <?>
  1136.  
  1137. 823    ??? [CLIENT]
  1138.  
  1139.     <channel> <?> ...?
  1140.  
  1141.     unknown command.  takes at least one additional argument besides the
  1142.     channel name.  no obvious effect
  1143.  
  1144. 824    emote [CLIENT, SERVER]
  1145.  
  1146.     client: <channel> "<text>"
  1147.     server: <channel> <user> "<text>"
  1148.  
  1149.     A variation of the public message command to indicate an action by
  1150.     the user.  Often implemented as the "/me" command in IRC clients.
  1151.  
  1152. 825    user list entry [SERVER]
  1153.  
  1154.     <channel> <user> <files shared> <speed>
  1155.  
  1156.     an 825 message is sent for each user in the channel specified by the
  1157.     830 message
  1158.  
  1159.     Example:
  1160.  
  1161.     Help testor3 0 3
  1162.  
  1163.     [This appears to be exactly the same format as the 408 message.  -ed]
  1164.  
  1165. 826    channel limit [CLIENT]
  1166.  
  1167.     <channel> <limit>
  1168.  
  1169.     sets the maximum number of users that may enter a channel.  <limit>
  1170.     is an integer value between 0 and 999999999.  setting it higher that
  1171.     this results in the limit being set to -1.  by default, created
  1172.     channels have a limit of 200.  there appears to be no restriction on
  1173.     any channel member changing the limit, and no notification is given
  1174.  
  1175. 827    show all channels [CLIENT, SERVER]
  1176.  
  1177.     no data.
  1178.  
  1179.     client request to show all channels, including "hidden" channels.
  1180.     the server also sends this message to terminate
  1181.  
  1182. 828    channel list [SERVER]
  1183.  
  1184.     <channel> <users> <n1> <level> <limit> "<topic>"
  1185.  
  1186.     the server sends a list of 828 commands, one for each channel,
  1187.     including "hidden" channels that don't show up in the normal channel
  1188.     list.
  1189.  
  1190.     <level> is the mimimum user level required for entry into a channel
  1191.     <limit> is the max number of users allowed in a channel
  1192.  
  1193.     <n1> is either 0 or 1.  seems to be 1 if the channel was user
  1194.     created, or 0 if a predefined channel???
  1195.  
  1196. 829    kick user from channel [CLIENT]
  1197.  
  1198.     <channel> <user> [ "<reason>" ]
  1199.  
  1200. 830    list users in channel [CLIENT, SERVER]
  1201.  
  1202.     <channel>
  1203.  
  1204.     client requests a list of all users in <channel>.  server responds
  1205.     with a 825 response for each user, followed by an 830 response with
  1206.     no data [why didn't they just use the 409 message? -ed]
  1207.  
  1208. 831    global user list [CLIENT]
  1209.  
  1210.     [returns permission denied.  -ed]
  1211.  
  1212. 832-869    missing.
  1213.  
  1214. 870    add files by directory [CLIENT]
  1215.  
  1216.     Format: "<directory>" "<file>" <md5> <size> <bitrate> <freq> <duration>
  1217.     [ ... ]
  1218.  
  1219.     This command allows a client to share multiple files in the same
  1220.     directory as a shortcut to multiple 100 (share file) commands.
  1221.     <directory> is the path which should be prepended to all the given
  1222.     filenames in the rest of the command.  <file> is the name of the file
  1223.     to share *without* its directory component.  When other clients do a
  1224.     browse/share, the real path will be reported as <directory>/<file>.
  1225.  
  1226.     The portion of this command after the <directory> may be repeated as
  1227.     many times as necessary for files in the same directory. NOTE: most
  1228.     servers will not accept commands of length longer than 2048 bytes
  1229.     so you still may need to break up the files into multiple commands
  1230.     if there are many files in a single directory.
  1231.  
  1232. 871-899    missing.
  1233.  
  1234. 900     connection test [SERVER]
  1235.  
  1236.         <ip> <port> <data>
  1237.  
  1238.         <ip>   - string,  ip address to connect to.
  1239.         <port> - integer, port to connect to
  1240.         <data> - string,  data to send to server.
  1241.  
  1242.         Try to connect to <ip> on <port> for atmost 1000 seconds.  If the
  1243.         connection succeeds send the <data> to target.
  1244.  
  1245.     [reported by Thomas van der Heijden <thom@bart.nl>]
  1246.  
  1247. 901     listen test [SERVER]
  1248.  
  1249.         <port> <timeout> <data>
  1250.  
  1251.         <port>    - integer, port to listen on
  1252.         <timeout> - integer, time to wait for connection in seconds
  1253.         <data>    - string,  data to send after connection has been made.
  1254.  
  1255.         Listen on <port> for <timeout> seconds. If a connection arrives,
  1256.         return <data> to sender.
  1257.  
  1258.     [reported by Thomas van der Heijden <thom@bart.nl>]
  1259.  
  1260. 902-1030    missing.
  1261.  
  1262. 3.  MD5
  1263.  
  1264. It looks like the vast majority of the files are hashed using the first
  1265. 299,008 bytes of the file.  There have been some cases where the hash
  1266. matches at 300,032 bytes, but no correlation has been drawn as to when that
  1267. happens.  The speculation at this point is that it might have to do with
  1268. the existence of a ID3v2 tag, or perhaps the file was sampled at 48kHz...?
  1269.  
  1270. The current method seems to be: skip id3v2, seek to frame sync and hash.
  1271.  
  1272. Note: the linux nap client (versions 0.7 - 0.9) seem to hash exactly 300,000
  1273. bytes, which is NOT what the official windows client does.
  1274.  
  1275. 4.  Client-Client Protocol
  1276.  
  1277. File transfer occur directly between clients without passing through the
  1278. server.  There are four transfer modes, upload, download, firewalled upload,
  1279. firewalled download.  The normal method of transfer is that the client
  1280. wishing to download a file makes a TCP connection to the client holding the
  1281. file on their data port.  However, in the case where the client sharing the
  1282. file is behind a firewall, it is necessary for them to "push" the data by
  1283. making a TCP connection to the downloader's data port.
  1284.  
  1285. 4.1  Normal Downloading
  1286.  
  1287. Regardless of which mode, the downloading client will first issue either a 
  1288. search(200) or browse(211) command to the server.  This returns a list of
  1289. files and information on the client sharin the file.  To request a download,
  1290. a get(203) request is sent to the server.  The server will respond with
  1291. a get ack(204) containing more detailed information.
  1292.  
  1293. This is the point at which the different methods diverge.  If the 204 get
  1294. ack says that the remote clients data port is 0, you must send a 500 request
  1295. to the server requesting that the remote client send the data to you.  In
  1296. this case you wait for the remote client to connect to your own data port.
  1297.  
  1298. In the case where the sharing client is not firewalled, you make a TCP
  1299. connection to the data port specified in the 204 message from the server.
  1300. The remote client should accept the connection and immediately send one
  1301. ASCII char, `1' (ASCII 49).  Once you read this char, you send a request
  1302. for the file you wish to download.  First send the string "GET" in a single
  1303. packet, then send
  1304.     <mynick> "<filename>" <offset>
  1305. where <mynick> is your napster user name, <filename> is the file you wish to
  1306. download, and <offset> if the byte offst in the file to begin the transfer
  1307. at (if you are downloading for the first time, and not resuming a prior
  1308. transfer, you should uses 0 to start at the beginning of the file).
  1309.  
  1310. The remote client will then return the file size, or an error message such
  1311. as "INVALID REQUEST" or "FILE NOT SHARED".  Note that the file size is not
  1312. terminated in any special way, and the best way to figure out the size is to
  1313. keep reading until you hit a character that is not a digit (it will usually
  1314. be 0xff which is the start of the MP3 frame sync header, but if a ID3v2
  1315. tag is present it might look different).  Immediately following the file
  1316. size is where the data stream for the file begins.
  1317.  
  1318. Once the data transfer is initiated, the downloader should notify the server
  1319. that they are downloading a file by sending the 218 message.  Once the
  1320. transfer is complete, you send a 219 message to indicate you have finished
  1321. the download.  Note that this is cummalitive, so that if you are downloading
  1322. multiple files, you send one 218/219 pair for EACH concurrent download--this
  1323. is how the server knows how many transfers you have going on.  Likewise,
  1324. the uploader should send one 220 messge for each upload, and one 221 when
  1325. each upload has finished.
  1326.  
  1327. 4.2  Firwalled Downloading
  1328.  
  1329. As described above, when the file needs to be pushed from a client behind a
  1330. firewall, the downloader sends a 500 message to the server.  This causes a
  1331. 501 message to be sent to the uploader, which is similar to the 204 message
  1332. for a normal download.
  1333.  
  1334. Once the uploader receives the 501 message from the server, they should make
  1335. a TCP connection to the downloader's data port (given in the 501 message).
  1336. Upon connection, the downloader's client will sent one byte, the ASCII
  1337. character `1'.  The uploader should then send the string "SEND" in a single
  1338. packet, and then the information:
  1339.     <mynick> "<filename>" <size>
  1340. where <mynick> is the uploader's napster user name, <filename> is the file
  1341. being sent, and <size> is the size of the file in bytes.
  1342.  
  1343. Upon receipt, the downloading client will either send the byte offset at
  1344. whcih the transfer should start, or an error message such as
  1345. "INVALID REQUEST".  The byte offset should be sent as a single packet
  1346. in plain ASCII digits.  Just as with above in section 4.1, a 0 byte offset
  1347. indicates the transfer should begin at the start of the file.
  1348.  
  1349. Each client should notify the server that they are uploading or downloading
  1350. with the 218/219 (downloading) or 220/221 (uploading) command pairs (see
  1351. section 4.1 for more detailed information).
  1352.  
  1353. 5.  Where to get more help?
  1354.  
  1355. Join the napdev mailing list by sending email to napdev-subscribe@onelist.com
  1356. or by visiting the community page http://www.onelist.com/community/napdev/.
  1357. This list is designed for open source napster developers to share information
  1358. about the specification or applications.
  1359.  
  1360. 6.  Acknowledgements
  1361.  
  1362. A big THANKS goes to the following people who contributed valuable information
  1363. to this specification:
  1364.  
  1365. Ben Byer <bbyer@rice.edu>
  1366. JT <jtraub@dragoncat.net>
  1367. Evan Martin <eeyem@u.washington.edu>
  1368. Colten Edwards (aka panasync@efnet) <edwards@bitchx.dimension6.com>
  1369. Thomas van der Heijden <thom@bart.nl>
  1370.